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Overview 

Content on the Next Generation internet needs to be highly adaptive. New interfaces and devices 
are emerging, the diversity of users is increasing, machines are acting more and more on users' 
behalf; and net activities are possible for a wide range of business, leisure, education, and 
research activities. 

To achieve maximum flexibility and reuse, content needs to be broken down into richly tagged 
fragments that can be combined and rendered appropriately for the user, task, and context. The 
Franklin content management prototype builds on this premise. It provides an end-to-end process 
from content creation and m eta-tagging to quality assurance and publishing. 

Franklin integrates several IBM technologies for its five components: content store, meta-data 
store, dispatcher, services and user interfaces. A high-level view of the components is shown in 
Figure I : Franklin Components. 




figure 1: Franklin Components 
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The content store-builds upon the Daedalus (a.k.a Trigger Monitor) technology from IBM 
Watson Research. [For full specification, see 

http:/Av3.watsonjbnixom/^^ Daedalus is designed to 

manage high numbers of rapidly changing content fragments. By maintaining an Object 
Dependency Graph, and by detecting changes to content, it manages pages on a web server or 
cached in a network router in a timely manner. 

The meta-data store manages tags that describe the functional and semantic role of each content 
fragment within the information collection. They may describe what the content is about, who 
the target audience is, and its relationship to a taxonomy or other fragments. The meta-data store 
also supports efficient searches. 

Networked services support the editor in content creation. They may assist the editor in meta- 
data creation, classification, summarization or translation. Instead of doing the task from 
beginning to end, the editor can accept, reject or modify the suggestions created by a service. 

The dispatcher's task is to delegate incoming requests to the content store, meta-data store and 
the services. The dispatcher presents a consistent application programming interface to the user 
interfaces. This Franklin API abides to the Web protocol for Distributed Authoring and 
Versioning (WebDAV) and to the Distributed Authoring Search Language (DASL) 
specification. 

The user interfaces communicate with the Franklin system through the API. Using the Editor UI, 
an editor can create and edit XML content fragments, upload XSL style sheets and multimedia 
objects, compose pages out of fragments, preview pages, review final published pages, and reject 
them or promote them to the final stage in the publishing flow. 

The Franklin system has also been integrated with Kitty Hawk, an IBM Notes based workflow 
engine. This workflow module can be turned on or off depending on the application needs. 

This document describes in detail the system requirements and setup, the architecture, 
components and features of Franklin; It covers the lessons learned, and provides a working 
example of a content collection managed with Franklin. In addition, it describes a lightweight 
version of Franklin, code-named Franklin Light, which satisfies the needs of small sites with no 
need for multiple Quality Assurance steps, or a scalable DB2 based search. 

System Setup & Configuration 

Before running an instance of Franklin to manage the content for a web site, you need to 
complete a number of installation steps. You also need to define the DTDs, the XSL style sheets, 
and the site map of the web site you intend to manage. This section outlines the required steps. 

Stepl: Install Franklin Server 

The Franklin Server runs on an AIX or NT server and requires the following software installed 
on the same machine: 

- Apache Web Server v. 1 .3 .6 or higher 

- WebSphere Application Server v.2.0 or higher 

- Java run-time environment 1.1.8 
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The Franklin server is distributed as a jar file, i.e.,- Franklirtjar. The distribution directory : 

pontains the following jar files that are required by Fr?(fWm: _xml4jjar, patbinl32 : jar 7 - - f Deleted; ] 

daedal us jar, lotusxsljar, xercesjar. 

Download the Franklin Server and associated components from 

http://rrankJin.aAeckinternetibm.eom/rranklin/d and place them in a 

directory accessible by the WebSphere Application Server. 

Step 2: Install DB2 for Meta-Data Store 

The DB2 database used by the Meta-data Store can run on the same machine or a different 
machine. It requires the following software: 

1) DB2 6.1 with DB2 XML Extender 7.1 

Download DB2 XML Extenders 7. 1 from IBM software website at 
http://www.software.ibm.com/db2 . Currently, XML Extenders is supported on Windows 
NT, AIX and Solaris. If you decide to use the XML Extender Administration Wizard 
make sure you review the XML Extender Administration Wizard Readme file to ensure 
you have the software prerequisites, JDK 1.1.x or XRE vl.l.x and JFC 1.1 with Swing 1.1 
or later. 

2) JDBC for DB2 IDBC 1 .20 

JDBC is included in the DB2 installation (db2java.zip) in the directory of sqllib/java. 



The steps to install DB2 and enable DB2 XML Extenders (which require root authority on ADQ: 

1) Install a version of UDB higher than 5.2. We have tested DB2 XML on NT for UDB 5.2 
and 6. 1 , and on ADC for UDB 6. 1 for DB2 XML XColumn function. 

2) Create a DB2 instance. In the included examples, we use the db2 instance name db2frnkl. 

3) Install DB2 XML Extenders 

4) Create a database m the instance. Also, create the tables and indexes based on the sample 
scripts we have provided. . 

5) Enable the database with XML Extenders 

6) Start JDBC on a port. For example, "db2jstrt 4000" opens port 4000 for JDBC 
connections. 



Step 3: Customize Server Initialization Flies 

Edit franklinServletlnitializatiorL properties [file and set the following variable to the desired 
directory in your setup: 

baseDir - base directory for all Franklin related files. 




All other variables \nfranHittServletInitialization.properties are relative to baseDir and should 
not be changed: 



dtdDir - directory for DTD and entity files 

xndDir - root of the directory hierarchy for XML files 
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assetsDir^ directory for all directories browsable by client UT, i.e, xslDir, publishDir, 
multimediaDir 

xslDir - directory for XSL style sheets 

publishDir - root of the directory hierarchy for HTML, HDML or DHTML files 
multimediaDir - root of the directory hierarchy for images, graphics, video and audio 
files 

Edit metastore. ini file and set the following variables to the desired directory in your setup: 

MetaStoreSe rve rIP - database host machine name 
MetaStoreServerPort - JDBC port number 
MetaStoreServerDBName — database name 
MetaStoreServerUserlD - database user name 
MetaStoreServerPassword - database password for the above user 
MetaStoreServerDriverCIassName - database JDBC driver name 
MetaStoreServerlnitialConnection - number of initial connections to the database 
MetaStoreServer Increment - number of additional connections to database 
MetaStoreChecklnXMLDir - temporary directory for XML files checked into meta store 
MetaStoreDADDir - directory for DAD files 

MetaStoreCacheSearchDir - directory for cached XML Search results 

Step 4: Configure WebSphere Application Server 

Start the WebSphere Administrative Console, refer to the WebSphere Quick Beginnings guide 
for details 

1. In the Tasks tab of the console* select Configure a Web Application and click the start task 
button 

a. Specify the Web Application Name, e.g., FranklinServer, click Next 

b. Choose the servlet engine, e.g., the ServtetEngine in the Default Server of the Default 
Host, click Next 

c* Specify the Web Application Web Path, e.g., /franklinserver, click Next 
d. Specify the CLASSP ATR* 

i. Add each of the jar files in the Franklin distribution to the classpath, i.e., franklin jar, 
daedalus jar, xml4j jar, lotusxsl jar, xerces j ar, patbin 1 32.zip 

ii. Add the db2java^ip file to the classpath, the db2java.zip Die is distributed with DB2, 
it is found under the sqllih/java subdirectory of the database instance home directory 

iii. Click Finished 

2. In the same Tasks tab, select Add a Servlet and click the start task button 

a. Select Yes to "Do you want to select an existing Servlet jar file or Directory that contains 
Servlet classes" and click Next 

b. Specify the path of the directory where franklin jar is located, click Next 

c. Select the Web Application that was created in the previous step, click Next 

d. Select the Create User-Defined Servlet option, click Next 

e. Specify the Servlet Name, e.g., dispatcher 

f. Specify the Servlet Class Name as comibm^tech.franklin.server.dispatcher.Dispatcher 
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g. Specify the Servlet Web Path List, for example /franklinserver/dispatcher, this is the web 
path that should be used by the client to access the franklin server, click next 

h. Add an init parameter with Init Parm Name as* baseDir and Init Parm Value equal to the 
directory where the franklin server configuration files are stored, e.g., 
/franklin/data/config 

i. Select the True option for Load at Startup; click Finished 

3. The configuration is complete you need to start the service, select the Topology tab 

a. Prior to starting the application, make sure that the database instance is running and that 
jdbc daemon is active (see previous section) 

b. Expand the topology tree and select the newly created application. The application will 
appear under the servlet engine that was selected in step 1 .b 

c. Right click the selection and on the popup menu select Restart Application 

4. The Franklin Server should be available at this point. In order to verity that everything is in 
order view the log files of WebSphere 

Step 5: Install Franklin Client 

The Franklin Client Java Application has been tested on Windows98/2000/NT. 

Download the Franklin Client Application Installer FranklirtEditor.exe from 
http://franldin.adtech.intemetib^ and run it. In addition to 

the Franklin Client, the following Java packages are required and are automatically installed by 
the Installer 

- Java 1 . 1 .8 run-time environment with Swing JFC 1.1.1 
XML4J package 

- WebDav package 

The Franklin Client Application Installer also creates the subdirectories required by the client 
under the chosen installation directory. You can change these directories as described in the next 
paragraph. 

After installation, customize the initialization file franklm.properties located in the root directory 
where you installed the Franklin Client application. You need to edit the variable browserPath to 
define the location of the web browser you wish to use to preview pages. Also, you can edit the 
variable tempDir if you wish to change the directory where temporary files are i§B§|. 






dispatcher - http://adtechibmus2 Abm.com/franklinservlei/ 

initXMLFile = xmUfranklinJnit.xml 

## modify browserPath to point to the web browser you wish to use for preview 

browserPath = ci/Program Files/Internet Explorer/iexplore.exe 

## modify tempDir to point to the directory where temporary files will be stored 

tempDir - Amp/ 

tempMediaDir = media/ 

tempHTMLDir = html/ 

tempXSLDir - xsV 

standalone P ~ false 

validateP = true 
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Step 6: Define Document Type Definitions (DTD) 

Franklin manages two types of content obj ^c\s y fragments and servables. 

A fragment is a content object that can be reused on several pages: 

- a simple fragment is a self contained XML file containing text data and metadata - for 
example, a product specification 

- a compound fragment is an XML rile that contains metadata and points to an 
accompanying file such as a video or image file, an XSL style sheet, or a hand-crafted 
HTML page 

- an index fragment is an automatically updated XML file that indexes any number of 
servables - for example a panel listing the five latest press release [Future: index 
fragments not available in current implementation] 

A servable ts an XML file that contains the text and meta-data for one final published page and 
imports reusable content from one or more fragments, and points to one of more style sheet 
fragments. 

Figure 2 shows a product page servable which includes content from six fragments, namely 
three text fragments, one image fragment and two style sheet fragments, and results in two final 
published pages. 

Insert Figure 2 here 

Before beginning to manage a content collection, you need to define the document type 
definitions, or DTDs, for each class of fragment and servable that will be managed by the 
application: Franklin uses the syntax of DTDs to define a document type. [See the XML 
specification at http://www.w3.org/TR/REC-xmi] 

In order for Franklin to manage DTDs correctly, all DTDs must abide to the Franklin following 
specifications: 

Franklin specification of fragment and servable DTDs 

t. The root element, to which you can give a meaningful name, must have a child node called 
system with the children nodes fragmentid, creator, modifier, great i out ime, 

LASTMODIFIEDTIME, PAGETYPE and CONTENTS I ZE . The NAME attribute of PAGETYPE must be 

set to either "fragment" or "servable". 

<• ELEMENT ROOT (SYSTEM, „) > 

<! ELEMENT SYSTEM { FRAGMENT! D, 

CREATIONTIME, 
LAS TMOD I FI EDT IME , 
CREATOR, 
MODIFIER, 
PAGETYPE 
CONTENTSIZE?) > 
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<! ELEMENT FRAGMENT ID 

< I ELEMENT CREATIONTIME 

<! ELEMENT LASTMODI FIEDTIME 

<! ELEMENT CREATOR 

<! ELEMENT MODIFIER 

<! ELEMENT CONTENTS I 2E • 

< I ELEMENT PAGETYPE 

< .'ATTLIST PAGETYPE 



( ft PCDATA) > 
( ftPCDATA) > 
(#PCDATA)> 
(# PCDATA) > 
(# PCDATA) > 
{# PCDATA) > 
(# PCDATA) > 

NAME (FRAGMENT ISERVADLE) 



"FRAGMENT* #FIXED> 



2. Ail items editable in the Editor UI need to be elements of the DTD, not attributes. For 
example, 

<! ELEMENT TITLE (# PCDATA) > 

<! ELEMENT SHORTDESCRIPTION (fr PCDATA) > 
< ! ELEMENT CATEGORY ( # PCDATA )> 



3. AJJ elements to be indexed for search must be of type PCDATA, and must contain the 
attribute SEARCH set to YES. For example, 

< l ELEMENT ROOT (TITLE, SHORTDESCRIPTION, CATEGORY,. ...)> 
<! ELEMENT TITLE (# PCDATA) > 

< I ELEMENT SHORTDESCRIPTION (#PCDATA)> 
<' ELEMENT CATEGORY (#PCDATA>> 

< 1 ATTLIST TITLE SEARCH (YES | NO) "YES " #FIXED> 

< 1 ATTLIST SHORTDESCRIPTION SEARCH (YES | NO) "YES " #FIXED> 
<! ATTLIST CATEGORY SEARCH (YESjNO) "YES" #FIXED> 

Future: Need to add SEARCH attribute. The SEARCH attribute will allow Franklin to 
automatically generate the DAD mapping for the DB2 XML Extenders.. 



4. Include the external entity reference that defines the user interface widgets recognized by the 
Franklin Editor UI. Each element that needs to be editable in the Editor UI must be of type 
PCDATA and contain the DATATYPE attribute set to the appropriate UI type. 

<! ENTITY - % UITYPES SYSTEM 

"http://f ran Klinserver /franklin /dtd/ui types . txt n > 

<! ATTLIST TITLE DATATYPE (SUITYPES;) "STRING" " #FIXED> 

< ! ATTLIST SHORTDESCRIPTION DATA YT PE (ftUITYPES; > "LONGTEXT" #FIXED 

PARSE - • (TRUE) I'TRUE" . #FIXED> 

If you wish a LONGTEXT widget to allow an editor to enter a limited set of HTML tags, add the 
PARSE attribute and set it to true. The supported HTML are: 

<p>, <ul>, <ol>, <sl>, <dl>, <dt>, <dd>, <ll>, <div> 

The file uitypes.txt is fixed and provided in the Franklin install in the dtdDir in the 
frcmklin.properties file. It contains the list of all UI widgets known to the Editor UI. {See section 
Editor UI Widgets for a detailed description of UITYPES) 

DATE | INTEGER | STRING I SHORTTEXT ) LONGTEXT 1 CHOICE | BROWSES ERVER | 
BR0WSELOCAL | ASSOCLIST 
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5. An element can appear as a drop-down menu in the Editor UI and restrict the editor to choose 
the value from a predefined set To accomplish this, set the DATATYPE attribute to the 
UITYPE "CHOICE" and the CHOICES attribute to a default value from a list of options. The 
options can be defined as an external entity for reuse across many DTDs. 



<! ENTITY % CATEGORYDEFS SYSTEM 

"http: //franklins erver/f r anklin/dtd/categorydef s . txt"> 

< ! ATTL I ST CATEGORY DATATYPE (%UITYPES;) "CHOICE** # FIXED 

CHOICES (%CATEGORYDEFS; > "NONE" #REQUTRED> 

For example, the options for category could be defined as the types of Netfinity servers: 

NONE | Netfinity_8500R | Netf inity_7000_MlO f Netfinity_5500_MlO | 
Netfinity_5600 I Netfinity_5500 

The Editor UI assumes that if the first word in the set of CHOICES is the string NONE, and the 
editor selects it, the element will not appear in the XML document 

6. A fragment can include other fragments as subfragments. If so, the entity reference that 
defines all subfragment types must be included in the DTD. The declaration of a subfragment 
must contain the subfragmentt ype attribute set to die appropriate type. 

<l ENTITY % SUBFRAGMENTTYPES SYSTEM 

"http : // franklins erver/f ranklin/dtd/subf ragment types .txt w > 
<! ELEMENT SUBFRAGMENT (# PCDATA) > 

< ! ATTLIST SUBFRAGMENT SOBFRAGMENTTYPE (% SUBFRAGMENTT Y PES ; ) "IMAGE FRAGMENT" 
#FIXED> 

Future: the subfragment syntax will be replaced by the XLirik syntax once it becomes a W3 
recommendation and XML4J and LotusXSL support the syntax. Until then, we will use 
subfragment elements as way to include content from another fragment 

An example of a fragment DTD, listfragmentdtd: 



<J ENTITY % SUBFRAGMENTTYPES SYSTEM 

"http; //franklinse rver/ franklin /dtd/3ubf ragment types ,txt"> 
< I ENTITY % CATEGORYDEFS SYSTEM 

"http: //f ranklinserver/ f r anklin/dtd/categorydef s . txt"> 
<! ENTITY % UITYPES SYSTEM 

"http : //f ranklinserver/f ranklin/dtd/ui types . txt"> 

< (ELEMENT LI STFRAGMENT { SYSTEM, TITLE, SHORTDESCRIPTION? , CATEGORY*, 

LISTITEM+)> 

<! ELEMENT SYSTEM ( FRAGMENT ID, CREATOR, MODIFIER, CREATIONTIME, 

LASTMODIFIEDTIME, PAGET YPE, CONTENTS I ZE?) > ' 
<! ELEMENT FRAGMENT I D (# PCDATA) > 

<! ELEMENT CREATIONTIME (#PCDATA)> 
<! ELEMENT LASTMODIFIEDTIME (#PCDATA)> 
<! ELEMENT CONTENTSIZE (#PCDATA)> 
< ! ELEMENT CREATOR ( ft PC DATA) > 

<! ELEMENT MODIFIER ( ft PCDATA) > 

< i ELEMENT PAGETYPE (#PCDATA)> 
< ! ELEMENT TITLE £#PCDATA)> 
<! ELEMENT SHORT DESCRIPTION (#PCDATA)> 
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<! ELEMENT CATEGORY (# PCDATA )> 

<! ELEMENT LISTITEM (LISTTITLE?, DESCRIPTION? , LIKK?, FOOTNOTE?) > 

<! ELEMENT LISTTITLE (#PCDATA}>/ 

< ! ELEMENT DESCRIPTION (#PCDATA>> 

<1 ELEMENT LINK (#PCDATA)> 

<! ELEMENT FOOTNOTE {# PCDATA) > 



< ! ATTLIST TITLE 



DATATYPE (%OITYPES;) #FIXED 
SEARCH {YESINO) "YES" #FIXED> 



"STRING" 



<! ATTLIST SHORTDESCRIPTION DATATYPE (%UITYPES; > 
< f ATTLIST CATEGORY 



# FIXED 



< 1 ATTLIST 
<! ATTLIST 

< ! ATTLIST 
<! ATTLIST 



SEARCH (YESINO) "YES" #FIXED> 

DATATYPE (%DITYPES; ) # FIXED 

CHOICES (%CATEGORYDEFS ; ) #IMPLIED 

SEARCH (YESINO) "YES* #FIXED> 
LISTTITLE DATATYPE (%UITYPES;) #FIXED 

DESCRIPTION DATATYPE (%UITYPES; ) #FIXED 

LINK DATATYPE (%UITYPES; ) # FIXED 

FOOTNOTE DATATYPE (%UITYPES;) #FIXED 



"SHORTTEXT" 
"CHOICE" 



"STRING"> 
"STRING "> 
"STRING"> 
"STRING"> 



Franklin specification of compound fragment DTDs 

A compound fragment contains a pointer to an accompanying file, such as a multimedia file, an 
XSL style sheet or a hand-crafted HTML file (i.e. ones that are not generated from XML by 
Franklin) The accompanying file is encoded as a binary object into the fragment for the duration 
of the communication between Editor UI and Franklin Server. Before check-in to the server, the 
Editor UI encodes the file as a binary object into the XML fragment At the receiving end, the 
dispatcher extracts it and decodes into the original format The reverse happens at check-out. 
This allows a single communication between the client and server when exchanging this type of 
fragments. 

1. A compound fragment DTD must use the following syntax to declare the inclusion of an 
external file: 

<! ELEMENT CONTENT (# PCDATA) > 

<» ELEMENT CONTENTS I R (#PCDATA)> 
<! ELEMENT CONTENTFILENAME (# PCDATA) > 
<! ATTLIST CONTENT DATATYPE (%OITYPES;) 

< 1 ATTLIST CONTENTDIR DATATYPE (%OITYPES;> 

<! ATTLIST CONTENTFILENAME DATATYPE (%DITYPES;) 



# FIXED "STRINGS 
#FIXED "BROWSESERVER*^ 
#FIXED K BROWSELOCAL"> ■ 



Franklin specification of group Index fragment DTDs 

Future: To be filled in 

Franklin specification of sen/able DTDs 

In the Franklin system, servables always result in one of more final published pages. The DTD 
must indicate the names of the XSL style sheets it can use for layout and where to publish the 
resulting pages. 
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1. A servable DTD must contain the following declarations: 



< l ELEMENT PUBLISHINFO 

<1 ELEMENT STYLESHEET 

<! ELEMENT PUBLISHDIR 

<! ELEMENT POBLISHFILENAME 

<IATTLIST STYLESHEET 



(STYLESHEET, PUBLISHDIR, POBLISHFILENAME) > 
( # PC DATA) > 
{#PCDATA)> 
(#PCDATA)> 
DATATYPE <%UITYPES;) # FIXED "CHOICE 1 * 
CHOICES (styleshheetl.xsl|stylesheet2.xsl) #IMPLIED> ' 
< ! ATTLIST POBLISKDIR DATATYPE (%OTTYPES;) #FIXED w BROWS ES ERVER * > 

< ! ATTLIST POBLISHFILENAME DATATYPE (%DTTYPES; ) #FIXED "STRING*^ 

2. A servable can include one or more subfragments. Each sub fragment serves a specific role 
within the servable and can be named in a meaningful way, for example MAINPHOTO, 
HIGHLIGHTS etc. Each subfragment must have an attribute that indicates the type of 
subfragment to include. The syntax to include a subfragment in a servable follows: 



< I ELEMENT MAINPHOTO 
< I ELEMENT HIGHLIGHTS 
<! ATTLIST MAINPHOTO 

SUBFRAGMENTTYPE 
< I ATTLIST HIGHLIGHTS 

SUBFRAGMENTTYPE 



(# PCDATA) > 

( # PCDATA) > 
DATATYPE (%UITYPES;) 
(% SUB FRAGMENT TYPES; ) 
DATATYPE (%UITYPES;) 
( SiSUBFRAGMENTTYPES; ) 



#FIXED "STRING" 
# FIXED "IMAGE FRAGMENT "> 
#FIXED "STRING" 
# FIXED "LI ST FRAGMENT n > 



3. A servable can be included in an automatically generated group index fragment. 
To be filled in 



An example of a servable DTD, productpage.dtd: 

<! ENTITY % UNIVERSAL SYSTEM 

"http : //f ranklinserver/£ ranklin/dtd/universal . dtd"> 
<! ENTITY % SUBFRAGMENTTYPES SYSTEM 

"http: //franldinserver/franklin/dtd/aubfragmenttypes. txt n > 
<! ENTITY % CAT EG0R YDEFS SYSTEM 

w http: //£ ranklinserver/f ranklin/dtd/categprydef s . txt" > 

<! ELEMENT PRODUCT PAGE (SYSTEM, TITLE, SOURCE? , COMMENT?, SHORT DESCRIPTION?, 
LONGDESCRIPTION?, KEYWORD* , CATEGORY* f RELATEDLINK*, 
PUBLISHINFO+, BRANDNAVIGATION, MAINPHOTO, GLANCE, 
HIGHLIGHTS , GROUPINDEX*) > 

<1 ELEMENT SYSTEM ( FRAGMENT ID/ CREATOR, MODIFIER, CREAT I ONT I ME , 

. LASTMODIFIEDTIME, PAGETYPE,. CONTENTSIZE?) > 

<! ELEMENT FRAGMENT ID (#PCDATA)> 

< i ELEMENT CREATIONTIME (# PCDATA) > 

<! ELEMENT LASTMODIFIEDTIME (# PCDATA )> 

< ! ELEMENT CONTENTSIZE <#PCDATA)> 

<! ELEMENT CREATOR {# PCDATA) > 

<! ELEMENT MODIFIER (#PCDATA)> 

< I ELEMENT PAGETYPE (#PCDATA)> 

< I ELEMENT TITLE (#PCDATA}> 

<! ELEMENT SOORCE (#PCDATA)> 

<! ELEMENT COMMENT (# PCDATA )> 

<! ELEMENT SHORTDESCRIPTION (#PCDATA)> 

< I ELEMENT LONGDSSCRIPTION (# PCDATA) > 

<! ELEMENT KEYWORD (f PCDATA) > 
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<! ELEMENT CATEGORY 

• < ! ELEMENT RELATEDLINK 

<! ELEMENT ORL 

<! ELEMENT LINKTITLE 

<! ELEMENT DOCTYPE 

<! ELEMENT DTDURL 

<! ELEMENT PUBLISHINFO 

<! ELEMENT STYLESHEET 

<! ELEMENT PUBLISHDIR 

<! ELEMENT PUBLISHFILENAME 

<! ELEMENT BRANDNAVIGATION 

<! ELEMENT MAINPHOTO 

< 1 ELEMENT GLANCE 

<! ELEMENT HIGHLIGHTS 

<! ELEMENT GROOPINDEX 

< ! ATTLIST TITLE 

< ! ATTLIST SOURCE 

< 1 ATTLIST COMMENT 

< 'ATTLIST SHORTDESCRIPTION DATATYPE 

<! ATTLIST LONGDESCRIPTION DATATYPE 
"SHORT TEXT" > 

<! ATTLIST KEYWORD 

<! ATTLIST CATEGORY 



(#PCDATA)> 
(URL, LINKTITLE) > 
(#PCDATA)>~ 
f#PCDATAJ> 
(#PCDATA)> 
(#PCDATA)> 

(STYLESHEET/ POBLISHDIR, PUBLISHFILENAME) > 
*(ftFCDATA)> 
(ft PCDATA) > 
( ft PCDATA) > 
(ft PCDATA) > 
(# PCDATA) > 
( ft PCDATA) > 
( ftPCDATA) > 
( ftPCDATA) > 

DATATYPE (%UITYPES;) ftFIXED 
(%UITYPES;) #FIXED 
(%UITYPES;) FIXED 
(%UITYPES;) ftFIXED 
(%UITYPES;) #FIXED 



DATATYPE 
DATATYPE 



*' STRING "> 
*' STRING" > 
STRING w > 
"SHORTTEXT"> 



DATATYPE 
DATATYPE 
CHOICES 
DATATYPE 



(%UITYPES;) 
(%UITYPES;) 



# FIXED 
ft FIXED 



"STRING" 
"CHOICE" 



£%CATEGORYDEFS; ) ftIMPLIED> 



(%0ITYPES; ) 
DATATYPE <%UITYPES;) 
DATATYPE {%UITYPES;) 
( % S UB FRAGMENTT Y PES ; ) 



<! ATTLIST URL 
<! ATTLIST LINKTITLE 
<! ATTLIST BRANDNAVIGATION 
SUBFRAGMENTTYPE 
< I ATTLIST MAINPHOTO DATATYPE (%UITYPES;) 

SUBFRAGMENTTYPE (%SUBFRAGMENT TYPES; ) 
< I ATTLIST GLANCE DATATYPE (%UITYPES; ) 

SUBFRAGMENTTYPE (% SUB FRAGMENTT Y PES; ) 
<! ATTLIST HIGHLIGHTS DATATYPE (%UITYPES;) 

SUBFRAGMENTTYPE (% SUB FRAGMENTT Y PES ; ) 
<! ATTLIST STYLESHEET DATATYPE (%UITYPES;) ftFIXED "CHOICE" 

CHOICES (web_product_index-xal | pdajproduct_irtdex.xsl) 
ft IMPLIED> J 

<l ATTLIST PUBLISHDIR DATATYPE (%UITYPES; ) #FIXED " BROWS ESERVER" > 
<! ATTLIST PUBLISHFILENAME DATATYPE {%UITYPES; ) ft FIXED "STRING"> 
<! ATTLIST GROUPINDEX DATATYPE (%UITYPES;) ft FIXED H STRING" 

SUBFRAGMENTTYPE (%SUB FRAGMENTT YPES; ) # FIXED "GROUPINDEX' , > 



ft FIXED "STRING" 
ft FIXED "STRING" 
# FIXED "STRING" 
ft FIXED LIST FRAGMENT " 

ftFIXED "STRING" 
ft FIXED n IMAGEFRAGMENT"> 

ftFIXED "STRING" 
ftFIXED **LIST FRAGMENT "> 
ftFIXED "STRING" 
ftFIXED "LIST FRAGMENT "> 



An example of a servable, 2-tsrv.xm] , which abides to productpage.dtd: 
<?xrol version« w l . 0 P ?> 

< ! DOCTYPE PRODUCT PAGE SYSTEM **http: //f ranklinserver/dtd/productpage. dtd"> 
<PRODUCTPAGE> 
<SYSTEM> 

<FRAGMENT I D>2 - t S rv . xml< / FRAGMENT I D> 
<CREATOR>Joe Moe</CREATOR> 
<MODIFTER> Jane Mane < /MOD I FIER> 
<CREATIONTIME>384738740383</CREATIONTIME> 
<LASTMODIFIEDTIME>38473874 0383;</LASTMODIFIEDTIME> 
<PAGETYPE>ServaJDle</PAGETYPE> 
</SYSTEM> 

<TITLE>Netfinity 8500R</TITLE> 
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<SCURCE>IBM PC Cojnpany</SOORCE> 

<SHORTDESCRIPTION>Mainf rame features bring extraordinary performance and 
reliability to a rack-optijnized 8 -way" server </SHORTDESCRIPTION> 

<LONGDESCRIPTlON>A great value in 8-way servers, the new Netfinity 8500R 
maximizes uptime and provides superior manageability for compute- intensive 
business intelligence, transaction processing and server consolidation 
* projects. </LOKGDESCRIPTION> 

<REYWORD> Hew< /KEYWORD> 

<K£ YWORD>Se rver < / KEYWORD > 

<KEYWORD> Pentium< /KE YWORD> 

<CATEGORY>Netfinity 8500 R< /CATEGORY > 

<CATEGORY>Small and Medium Business</CATEGORY> 

<RELATEDLIKK> 

<URL>f tp : //ftp . pc . ibm. coia/pub/pccbbs /pc_3ervers/8500rf .pdf </URL> 
<LINKTIT!LE>Whi te pape r < /LINKTITLE> 
</REliATEDLINK> 
<PUBLISHINFO> 

<PUBLISHDIR>/web/netfinity/</PDBLISHDIR> ■ 
<PDBLlSHFILENAME>index . htHll< /PUBLISH F I L£NAME> 
<STYLESHEET>web_product_index . xsl</STYLESHEET> 
</PUBLI5UINFO> 
<PUBLISHINFO> 

<PUBLISHDIR>/pda/netfinity/</FOBLISHDIR> 
<PUBL.ISHFILENAME>index .html</PUBLIS:HFILENAME> 
<STYLESHEET>pdajproduct_index . xsl< / STYLESHJ2ET> 
</PUBLISHINFO> 

<GROUPINDEX>4 4 4-i f rg . xml< /GR0UPINDEX> 
<MAINPHOTO SUBFRAGMENTTYPE» n IMAGEFRAGMEMT' T > 

222-bf rg . xml< /MAIN PHOTO 
<HIGHLIGHTS SDBFRAGMENTTYPE-"LI STFRAGMENT M > 

444-tfrg.xml</HIGHLIGHTS> 
</PR0DUCTPAGE> 

Once all DTDs for the collection have been defined, save them in the directory defined by the 
variable dtdDir in the franHin.properties file. 

After updating, adding or deleting any DTDs, update the files configDir/dtds.xmI and 
dtdDir/subfragmenttypes+txt to reflect the current DTDs. Also remember to define a DAD file to 
for each DTD. (Future: DAD explanation should be expanded) 



Step 7: Define Style Sheets 

For each servable DTD, you need to define one or more XSL style sheets that will be assembled 
with the servable XML and the XML of any subfragments into the final published pages. A style 
sheet is written using the XSL syntax to produce HTML, DHTML; HDML or other desired 
output [See the XSL Transformations syntax at http^Avww.w3.org/TR/^J| 

Franklin specification of XSL style sheets 

Because the servable includes content from subfragments, the style sheet must be written to work 
on the so-called expanded servable. Before page assembly, a servable is temporarily rewritten to 
include the content of all its subfragments. Because the XLink standard has not been finalized, 
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XSL style sheets cannot access content stored in subfragment files outside the servable. FrankJin 
implements a temporary solution that mimics the XLink functionality by expanding the servable. 
This is demonstrated by the expanded product page 2-tsrv:xmL 

<?xml version-"!.. 0"?> 
<!DOCTYPE PRODOCTPAGE SYSTEM 

w http ; //your f raniainserver /dtd/productpage . dtd"> 
<PRODOCTPAGE> 
<SYSTEM> 

< FRAGMENT I D> 2 - 1 s rv . xml< / FRAGMEKTI D> 
<CREATOR>Joe Moe < / CREATOR> 
<MODIFIER>Jane Mane</M0DIFIER> 
<CREATIONTIME>3847387403B3</CREATIONTIME> 
<LASTMODIFIEDTIME>384738740383</LASTMODIF1EDTIME> 

< PAGET Y P E>$ e r vabl e < / PAGET Y P E > 
</SYSTEM> 

<TITLE>Netfinity 8500R</TITLE> 
<SOURCE>IBM PC Company</SOURCE> 

<SHORTDESCRIPTIOtf>Mainframe features bring extraordinary performance and 
reliability to a rack-optimized 8-way server</SHORTDESCRIPTION> 

<LONGDESCRIPTION>A great value in 8-way servers, the new Netfinity 8500R 
maximizes uptime and provides superior manageability for compute-intensive 
business intelligence, transaction processing and server consolidation 
projects. </LONGDESCRIPTION> 

<KEYWORD>Wew</KEYWORD> 

<KEYWORD>Se rve r< /KEYWORD> 

<KEYWORD>Pentium< / KEYWORD> 

<CATEGORY>Netfinity 8500R</CATEGORY> 

<CATEGORY> Small and Medium Business*: /CATEGORY> 

<RELATEDLINK> 

<DRL> f tp : //f tp . pc . ibm. com/pub/pccbbs/pc_servers/8500rf .pdf </ORL> 
<LINKTITItE> White paper</LINKTITLE> 
</RELATEDLINK> 
<PUBLISHINFO> 

<PDBLISHDIR>/web/netfinity/</PUBLISHDIR> 
< POBLI SHFI LENAME>index -html</PUBLISHFILENAME> 
<STYLESHEET>webjproduct_index .xsl< /STYLESHEET> 
</PUBLISHIUFO> 
<P0BLISHINFO> 

<PDBLlSHDIR>/pda/netfinity/</PUBLISHDIR> 
<POBLISHITILENAME>index .html</PDBLISHFILENAME> 
<STYLESHEET>pda_prodUCt_index . xsl</STYLESHEET> 
</PUBLISHIKFO> 

<GRO0PINn£X>4 4 4 r i f rg , xml< /GROUPINDEX> 
<MAINPHOTO SUBFRAGMENTTYPE=" IMAGEFRAGNTENT " > 
<IMA£3EFRAGMENT> 
<StSTEM> 

<PRAGMENTID>222-bfrg . xml</FRAGMENT ID> 
<CREATOR>BOB< / CREATOR> 
O40D tP!ER>BOB< /MOD IFIRR> 

<CBRATICOTIMB>3 8 47 3 874 0383</CREATICNTIMB> 
<IASTM0DIPIEDTIME>38 4738 7 4 03 83</lA30MODIFISDTIME> 
<PAGETYPE>Fragment</PAGgTYPE> 
<C0NTBKTS TZE>40 0</ CONTENTS X 3E> 
</SYSTEM> 

<TITLB>The Netfinity 8500R ikcg© jpeg</TITI*E> 

< SHORTDSSCRIPTION>Ne tfiJli ty 85C0R</SHQRTDSSCRIPTION> 
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<CGNTENTDIR>/ imago s /pr od_imaga a / < / CONT2NTD TR> 
<COKTENTFILENRME>8 5 0 OR_large . jpg< / CONTENTS* ELBNAM£> 
<OONTBOT/> 
</ IMAGE FRAGMENT> 

</MAINPHOTO> 

< HIGHLIGHTS SUBFRAGMEUTTYPE-" LI ST FRAGMENT "> 
<I*ISTFRAGMBNT> 
<SYSTEM> 

<FRAGMENTXD>4 4 4 - tf rg . »ttl< /FRAGMENT ID> 

<CREATOR>BOB</CREATOR> 

<MODIFIER>BOB</MC3DIFXSH> 

<CRBATI0NTIMK>3B473e74 0383</ CRKAIIONTIME> 
<PAGSTYPE>Fragroent.</PAGETyPE> 

<XAST14DDIFIEDTIMEI>384738740383</I»ASTMOTrETED5TME> 
</SYSTSM> 

<TITI^>Bighlight8 of the B500R</*ITLE> 
<CATBGQRY>ftetfinity 8500R</CATBGORY> 
<LI£raiTEM> 

<TITLE>Light-Path DiagnoBtics</TITXE> 
<BOD Y>l*i gh tod guidance system to assist In quick 
identification of failing components , similar to the lights in & copier 
that identify the location of a paper }am.</BOD*> 
</I.I3TITKM> 
<LISTIYEM> 

<TITXE>Active PCI teohnology</rXTXE> 
<BODX>Bnables IBM's unique hot-add PCX, letting you 
add client systems, balance network traffic or increase storage capacity 
without shutting the system down. </BODY> 
</LISTITEM> 
</l*ISTFRAGMENT> 
</HIGHLIGHTS> 
</PRODUCTPAGE> 

Any Xpath expressions in the style sheet that refer to subfragment content will be locaJ to the 
servable. The following example XSL style sheet, web_productjndex Jtsl , produces a simple 
HTML page by displaying content form the servable as well as the two subfragments: 

<?xml veraioii="l . 0 W ?> 

<xsl : stylesheet xmlns :xsl="http: //www. w3 .org/XSL/Trans form/ 1 . 0 M > 



<xal: template match- n PROD0CTPAGE"> 
<HTML>. ;.. - - 

<HEAD> 

<TITLE><xsl : value-of aelect- ,, TITLE"/></TlTl.E> 

<META NAME-"source-xml M CONTENT—" { SYSTEM/ FRAGMENTID) **/> 

<META NAME="source-xsl* ? CONTENT 3 "web pr o due t_ index. xsl n /> 

</HEAD> 

<B0DY> 

<TABLE CELLPADDING^O* CELLSPACING-"©" BORDER-" 0" WIDTH- "451 "> 

<TR> 

<TD> 

<! — title section — > 

<F0NT COLORS "#003399" SIZE**" +3" FACE— M T izne s New Roman"> 

<xal: value-of select= M TITLE"/> 

</FONTXBR/XBR/> 
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<l — end title section — > 

<! — short description section — > 

<BXFONT SIZE= W -1" FACE="Arial**> ." . 

<xsl rvalue -of select="SHORTDESCRIPTION"/> 

</FONTXBR/XBR/X/B> 
<t — end short description section — > 
</TD> 
</TR> 
<TR> 
<TD> 

<I — photo section — > 

<IMG HEIGHT" "110" WIDTH- "140" 
SRC= n /multimedia { MAI PHOTO/ 1 MAGEFRAGMENT /CONTENT DIR} {MAINPHOTO/IMAGEFRAGMEN 
T /CONTENT FILENAME) n BORDER= M 0" 

ALT="MAINPHOTO/ IMAGEFRAGMENT/SHORTDESCRI PTION w ></IMG> 

<I — end of photo section --> 

</TD> 

</TR> 

</TABLE> 

<! — Highlights section — > 

<TABL£ B0RDER= M 0' 1 CELLSPACING=* n Q M CELL PADDING- w 5 " WIDTH="451"> 
<TR> 

<TD COLSPAN-"2 n WIDTH="451"> 

<BXFQNT SIZE=*"-1" FACE="Arial">Highlights of the 

<xsl:value-of select="TITLE"/> 

</FONTX/B> 
</TD> 
</TR> 

<xsl : apply-templates select* 3 "HIGHLIGHTS /LI STFRAGMENT/LIST"/> 
</TABLE> 

<I — End of Highlights section — > 

</B0DY> 

</HTML> 

</xsl : tempi at e> 



<xsl : template ma t Ch= " / P RODUC T P AG E /H I GH L IGH T S / L I ST FRAGMENT " > 
<xsl:for-each select= M LISTITEM ,t > 
<TR> 

<TD WIDTH="151" VALIGN="TOP"> 

<FONT size-»"-l" face="Arial"x X 3l : value-of select» n TITLE M /x/FONT> 
</TD> 

<TD WIDTH="30CT VALIGN="TOP"> 
- <FOWT size-"-l? face^"Arial"xx3l:value-of select=' T DODY"/></FONT> 

</TD> 

</TR> 
</xsl : for-each> 
</xsl : template> 
</xsl : stylesheet> 



Once all XSL style sheets for the DTDs have been defined, add them to the CHOICES list of the 
STYLESHEET element in the appropriate DTDs. 

Then, check them in to the /xsl directory using the Franklin Editor. 
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[Add here, the definition of a debug style sheet, what is should do, and where it should be saved 
on the server] 

Step 8: Create Directory Structure 

Create the directory structure that corresponds to the site map of your application. Under 
publishDir create the HTML directories, and under multimediaDir the multimedia directories. 

If your site is published to more than one audience segment or device, define several sibling 
directory structures under publishDir. For example, a site published for two devices, one for 
browsing all content using a web browser, and another for browsing only the news section using 
a pda browser, could have the following directory structure: 

publishDir/web/ 

publishDir/web/news/ 

publishDir/web/products/ 

publishDir/pda/ 

publishDir/pda/news/ 

multimediaDir/i mages/ 

multimediaDir/audio/ 

When an editor authors a servable, the PUBLISHDIR element of the servable will be presented 
in the UI with the BROWSESERVER widget This widget allows the editor to browse the 
directory structure under assetsDir and select where to save the resulting file. Similarly, when 
editing a multimedia object, the widget allows the editor to browse the directory structure to 
select where to save the binary file. 

Step 9: Configure Web Server 

To browse the published sites, set up a web server for each sibling site. Configure the Document 
Root variable to point to the top of the directory hierarchy of a sibling site. The example below 
assumes that the baseDir in franklirtServletlnitialization.properties is set to *Vfranklin/data/*': 

For the example in the previous section, you would set up two web servers: 

Web Server 1: DocumentRoot V franklin/data /publish/ web/" 
Web Server 2: DocumentRoot Vf ranklin/data/publish/pda/" 

Also, add the aliases below to the configuration file of Web Server 1 and 2. 

Alias /dtd/ Vfranklin/data/dtd/" 

Alias /xsl/ Vfranklin/data/asseta/xsl/" 

Alias /multimedia/ w /franklin/data /as sets /multimedia/" 

Alias /xml/ "/frankl in/data /xml rt 

Set directory browsing "on" so that you can easily browse the DTDs and verify the uploaded 
XML files, XSL style sheets, and multimedia files. 
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Step 10: Define Roles & Users 

Before running the Editor UI, you need to define the allowed roles and users of the Franklin 
system. A role is defined by the list of DTDs the role is allowed to edit A user is defined by one 
or more roles. 

To define new roles, edit the file configDir/rolesjcml by importing the DTD configDir/roles.dtd 
to an XML editor such as Xeena from IBM alphaworks, (Future: use the Editor UI to edit the 
file) 

The DTD roles.dtd: 

<! ELEMENT ROLES <ROLE*)> 

< ! ELEMENT ROLE ( ROLENAME , DTD* ) > 

<! ELEMENT ROLENAME <#PCDATA)> 

< ! ELEMENT DTD <#PCDATA)> 

An example roles.xml defines two roles, FragmentEditor and Editor and associates the allowed 
DTDs to each: 

<?xml versioa^LO" encoding^"UTF-8"?> 
<ROLES> 

<ROLE> 

<ROLENAME>FragmentEditor</ROLENAME> 

<DTD>http ://f ranklinserver/dtd/ text fragment .dtd</DTD> 
<DTD>http : //f ranklinserver/dtd/listf ragment .dtd</DTD> 
<DTD>http : //f ranklinserver/dtd/audiof xagment .dtd</DTD> 
<DTD>http : //f ranklinserver/dtd/videof ragiaent..dtd</DTD> 
<DTD>http : //f ranklinserver/d td/ image fragment ,dtd</DTD> 

</ROLE> 

<ROLE> 

<ROLENAME>Edi to r< /ROLEN AME> 

<DTD>http : //f jcanklinserver/dtd/textf ragment ,dtd</DTD> 
<DTD>http: //franklinserver/dtd/newsarticle. dtd</DTD> 
<DTD>http;//franklinserver/dtd/productpage.dtd</DTD> 
</ROLE> 
</ ROLES > 

To define new users, edit the file configDir/usersjcml by importing the DTD configDir/vsers.did 
to an XML editor. 

The DTD users.dtd: 

<! ELEMENT USERS (USER*)> 

<! ELEMENT USER (NAME, EMAIL, PASSWORD, ROLE+) > 

<! ELEMENT NAME (# PCDATA) > 

<[ ELEMENT EMAIL (# PCDATA) > 

<! ELEMENT PASSWORD (# PCDATA) > 

<! ELEMENT ROLE (# PCDATA) > 

An example users .xml defines two users, each with one or more roles. 

<?xml version="1.0 ,T encodings M UTF- 8 "?> 
<USERS> 
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<D3ER> 
<NAME>Joe Moe</NAME> 
<EtIAII.> joegus . ibm. com</EMAIL> 
<PASSWORD>joe</PASSWORD> 
<R0LE>FraginentEditor</ROLE> 
<ROLE>Edi'tor</ROLE> 

</USER> 
<USER> 
<name> J an e Hane</NAME> 
<EWAlL>jane8us.ibm.com</EMAIL> 
<PASSWORD> j ane< /PASSWORD> 
<ROLE>Edi tor < /ROLE> 
</USER> 
<DSER> 
</D3ERS> 

When the Franklin server is initialized, the Dispatcher module runs GlobaisJoadinfoO- This 
method merges users.xmJ, rolesjcml and dtds.xml into one DOM in memory for fast access. The 
method verifies that all roles named in users.xml have a definition in rolesjcml It also verifies 
that all DTDs named in rolesjcml are defined in dtds.xml and exist in the named directory. If any 
discrepancies are detected, the server prints out a warning message. (Future: the verification still 
needs to be implemented.) 

(Future: if any of the configuration files have changed after the server was last initialized, the 
files will get reloaded and the DOM will get refreshed. This will not have an effect on any users 
currently logged on.) ' 

Editor Interface & Dispatcher Communication 

After installing the Editor User Interface application and completing the customization described 
in Section Install Franklin Client, launch the application from the Franklin Editor icon on the 
desktop. 

All communications between the Editor UI and the Franklin Dispatcher follow the WebDAV 
protocol. [See the full specification at http://www.webdav.org/specs/! 

The HTTP header of a Client request always contains the following attributes with ACTION 
replaced by PUT, GET, LOCK or UNLOCK, franklinservername replaced by the name of the 
Franklm server the client is communicating with, and length replaced by the length in bvtes of 
the body section. J 

ACTION /filename HTTP/1.1 
Host: fxankllnservezname 
Content-type: text/xml,- chaxset-"utf-8 r ' 
Content-Length: length 

The body of the Client request contains the XML document to be checked into the server or a 
DASL search query. 

The HTTP header of the Dispatcher response always contains the following attributes with 
errorcode and message replaced by the standard codes listed in Appendix 1 . 
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HTTP/1 . 1 erzorcode message 
■ Con tent -Type: text/xml; charset«"utf-8" 
Content -Length t length ' ' 

The format of the body of the Dispatcher response depends on the request and whether the 
request was successful ly completed or not. 

A special format used tor the response follows the DTD below. In the further examples the use 
of the elements will become obvious. * 

<! ELEMENT RESPONSE (PROCESS, STATUS, ERRORCODE, MESSAGE, SYSTEM' LOCK^»> 
< 1 ELEMENT PROCESS f*PCDATA)> ' LOCK?)> 

<! ELEMENT STATUS (#PCDATA)> 
<! ELEMENT ERRORCODE {#PCDATA)> 
< ! ELEMENT MESSAGE " (#PCDATA}> 

<! ELEMENT SYSTEM (FRAGMENTID, CREATOR , MODIFIER, CREATIONTIME 

LASTMODI FIEDTIME/ PAGETYPE, CONTENTSIZE?) > *- K ***»A±ONrXME / 
<! ELEMENT FRAGMENT ID (# PCDATA )> 

<! ELEMENT CREATOR (# PCDATA) > 

< ! ELEMENT MODIFIER (#PCDATA)> 
< ! ELEMENT CREATIONTIME (#PCDATAJ> 



<! ELEMENT LASTMODIFIEDTIME (#PCDATA)> 



< ! ELEMENT PAGETYPE 
< ! ELEMENT CONTENTS I ZE 
<• ELEMENT LOCK 
<! ELEMENT LOCKEDBY 
< I ELEMENT LOCKTIME 
< ! ELEMENT LOCKTOKEN 



(#PCDATA)> 
(# PCDATA )> 
(LOCKEDBY, 
(# PCDATA) > 
{# PCDATA) > 
(# PCDATA) > 



LOCKTIME , LOCKTOKEN ? ) > 



Login 

^J>r log? in using the user name and password defined by the Franklin administrator as 
defined in Section Define Roles & Users. 

Client request: 



GET / xmX/ frank lin_init.xml HTTP1.1 
Host : f ranklinservar/f ranklinservlet 
Content -Type: text/xml; charset- n utf-8 w 

Authorization: "Basic " f encode Base64 (username + 



+ .password) 



If Je user name is not defined or if the password is entered incorrectly, the dispatcher responds 
with the appropriate error. Dispatcher response: H 



HTTP/1.1 401 SC_UNAUTHORJ ZED 
Content-Type: text/xml; charset^utf-8" 
Content-Length: length 

<?xml version» B l.nt , ?> 
<RESPONSE> 

< PROCESS>l ogin< / PROCES S> 
<STATOS >A 0 lf< /STATUS > _ 
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<ERRORCODE>U10K/ERRORCODE> 

<MESSAGE>User Joe Doe not defined</M£SSAGE> 
</RESPONSE> 

If login succeeds, as described in Section Dispatcher: Session Management, the Dispatcher adds 
the user to the currentusers hash table and generates a unique session identifier, sessionld. All 
subsequent requests from the Editor UI must contain sessionld in the HTTP header. 

The dispatcher responds to a successful login request by generating the franklin Jnitjcml 
document that corresponds to the user's roles, references the DTDs the user is allowed to edit, 
and specifies the attributes, operators and allowed values for the Search UI. Dispatcher response: 

HTTP/1.1 200 OK 

Content-Type: text/xml; charset«"utf-8" 
Content-Length: length 
Sessionld: 175a :dc8e0da306: -8000 

<?xml Version*"! . 0" encoding/="UTF-8"?> 
<FRANKLIU_INIT> 
<SEARCH> 

<ATTRIBUTELIST> 

<ATTRIBUTE displaynarae="Crea tlon Date* naine="CREATIONTIME" 
class= T, Tiine n /> 

<ATTRIBOTE displayname="Last Modified Date" 
name="LASTMODIFIEDTIME" cla3S- n Time"/> 

< ATTRIBUTE di3playname«"Creator" name" "CREATOR" c las s«" Name V> 
< ATTRIBUTE di5playname=" Document Type" name="DOCTYPE" 
class- "Selection" opt ions- "TEXT FRAGMENT | LI ST FRAGMENT | IMAGE FRAGMENT | 
AUDIOFRAGMENT | V I DEO FRAGMENT J INDEXGRODP | PRODUCT PAGE | SOMESERVABLE"/> 

. <ATTRIBUTE displayname»"Page Type" name^PAGETYPE" 
class-"SelectionV op tions=" Fragment I Servable"/> 

< ATT R I BUT E displaynarae^Keyword" riame=" KEYWORD* class e ="Text"/> 
< ATTRIBUTE displayname«" Category" name- "category" 
las3= n Selection" option3~" Netf inity_8500R J Netfinity_7000_MlO I 
Netfinity_550O_MlO ! Netf inity_5 600 | Netf inity_5500 n /> 
</ATTRIBUTELIST > 
<CIiASSIiIST> ■ 

<CLASS nanie='*Time"> 

< OPERATOR name= ">="/> 
<OPERATOR name="< = ' , /> 
< OPERATOR namo="= TT /> 
<VALUE datatype="date"/> 
< /CLASS > 

<CLASS name="lnteger"> 

' <OPERATOR name«">«"/> 

<OPERATOR name= M fi#60;="/> 

< OPERATOR name= M ="/> 

<VALUE datatype="integer"/> 
</CLASS> 

<CLASS name="Name"> 

<OPERATOR najne»"is' T /> 

<OPERATOR name="isn*t w /> 

< OPERATOR name=" starts with"/> 

<VALUE datatype- M string"/> 
< /CLASS > 
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< CLASS name="Text fI > 

<OPERATOR name« ,, i9 , 7> 
< OPERATOR name-" starts with"/> 
< VALUE datatype=*"string"/> 
</CLASS> ' 

<CLASS name*= w Selection"> 

<OPERATOR name="is"/> 
<0PERATOR naiae- M isn , t w /> 
<value datatype- w choi ce"/> 
</CLA3S> 
</CLASSLIST> 
<RESULTS> 

< ATTRIBUTE displayname=*"Last Modified Date" name= "LASTMODI FI EDT IME " 
class-"Tinie ,, /> 

< ATTRIBUTE displaynaine="Creator" name="CREATOR ff class="Name n /> 
<ATTRIBOTE displayname=> "Title" name- "TITLE" cla3S«"Text "/> 
<AT TRIBUTE .display name-" Document Type" narae^^DOCTYPE" 
lass- "Select ion" /> 
</RESULTS> 
</SEARCH> 

<ROL£ name="FragmentEdltor" displayname*" Fragment Editor"> 
< FRAGMENTS displayname-Tragraen t n > 
<DTD- displaynarae="Text" 
hre f « "ht tp : / / franklinserver /franklin /dtd/textf r agment . dtd M /> 

<DTD displayname= t "List r * 
hre f=» "ht tp : f It ran klinserver/f r anklin/dtd/list fragment .dtd"/> 

<DTD displaynaiae« n Audio M 
href-"http://franklinserver/franklin/dtd/audiof ragment.dtd"/> 

<DTD displaynaiae-"Video" 
href="http: //f ranklinaerver/f ranklin/dtd/videofragment.dtd n /> 

<DTD display name=" Image" 
hre£- w http://franklinserver/franklin/dtd/imagef ragment .dtd"/> 
</FRAGMENTS> 
</ROLE> 

<ROLE name= "Editor" displayname= n Editor "> 
< FRAGMENTS displayname^Fragment "> 
<DTD dlsplayname-^Text" 
href="http: //franklinserver/f ranklin/dtd/textf ragment . dtd"/> 
</FRAGMENTS> 

<SERVABLES di3playname="Page rr > 

<DTD digplaynaiae= n News Article" 
href-"http : //f rankliaserver/f ranklin/dtd/newsarticle . dtd M /> 

<DTD displayname=" Product Page" 
hre£~"http;//franklinserver/ffranklin/dtd/productpage.dtd"/> . 
</SERVABLES> 
</ROLE> 
</ FRANKLIN INIT> 



From this frarddinjnitxml document, the Editor UI builds the File > New Fragment and File 
>New Page menus. It also maintains the mappings between display names and DTD URLs in a 
hash table. 

The Editor UI can be set to load all DTDs at this point, if it is important tp enable off-line 
editing. We have chosen to load a DTD from the server upon demand for a faster startup process. 
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At this point, the editor is able to either create new content or search for existing content in the 
system. 

Create new content 

The File > New Fragment menu lists all fragments and the File > New Page menu lists all 
servable pages the editor is allowed to create or edit- If the editor selects to create a new 
fragment, e.g. a TEXTFRAGMENT, the Editor UI gets the DTD from the appropriate URL and 
automatically generates a template from the DTD, as shown below; 

[Include screenshot here] 

In parallel, the Editor UI maintains in memory a DOM corresponding to the DTD. 
Editor UI Wfdgets 

The Editor UI uses the DATATYPE attributes in the DTD to generate the appropriate Java 
widget in the user interface. If an element does not contain a DATATYPE attribute no input is 
allowed for that element. Children elements may still contain DATATYPE attributes to specify 
their user interface. The mapping between Franklin UTTYPEs and Java widgets are given below: 

date => JtextField 

integer -> JtextField 

string => JtextField 

shorttext -> JtextArea (scrolling) 

longtext =»> JtextArea (scrolling) 

choice =>> JComboBox(with Def aultComboBoxModel to hold the data) 

browselocal => JtextField (with JfileChooser to select local file) 
browseserver -> JtextField (with custom JFrame to browse server 

directory) 

Each Java widget is encapsulated in a set of classes that include additional functionality. For 
example, if an element in the DTD is required, e.g. TITLE, the widget will be highlighted (e.g. 
colored brightly) to help the editor distinguish which fields must be filled in. If an element can 
appear more than once, e.g. KEYWORD, +/- buttons appear next to the widget that allow 
duplicating the widget or group of widgets. 

BODY tags are handled specially within the system. The system assumes that BODY tags are 
composed of 1 or more PARAGRAPH tags. Typically, this' is represented by a longtext widget in 
the user interface. Blank lines in the input are interpreted as paragraph separators. When 
constructing the DOM object, these paragraphs are composed within the outer BODY tag. 

Check-in of New Fragment 

When the editor has filled in the template in the UI, clicking on the check-in icon verifies that all 
required elements are filled in. If so, the DOM in memory is populated with the data in the UI 
widgets. New nodes are added if new instances of an element have been created using the +/- 
buttons. Nodes are removed from the DOM if optional fields have not been filled in. Once the 
DOM mirrors exactly the UI, the document is transformed to an XML string and a request is sent 
to the Dispatcher with the XML as the body. 
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Note that the only time a check-in request to the Franklin Dispatcher does not include the file 
name coatziningfragmentid is when uploading a new fragment The absence of afragmentid 

indicates to the server that a new, unnamed fragment is being checked-in. The Dispatcher assigns 

| j^iguei^ toaUfiBgmente. _ - (paietedT 

Client request: 

POT fragmented HTTP1.1 
Host: franklin server/ franklin servlet 
Con tent -Type : text/xml; charset="utf-8 w 
Seasionld: 175a :dcBe0de306 : -8000 
Content-Length: length 

<?xml version**" 1. 0"?> 
<!D0CTYPE TEXTFRAGMENT SYSTEM 

"http : //adtech . ibmus2 . ibra. com/f ranklin/dtd/text fragment . dtd" > 
<TEXT FRAGMENTS 
<SYSTEM> 

<FRAGMENTID/> 

<CREATOR/> 

<M0DIFTER/> 

<CREATI ONTTME /> 

<LASTMODIFlEDTIME/> 

< PAGET YPE/> 

<CONTENTSI ZE/> 
</SYSTEM> 

<TITLE>This is the title of this textf ragntent</TITLE> 
<BODY> 

<PARAGRAPH>This is the document body</PARAGRAPH> 
</BODY> 
< /TEXTFRAGMENT > 

If check-in is successful the Dispatcher returns the SYSTEM data of the XML document filled in 
with the newly created unique fragmentld, and the authoring information, as described in Section 
XXX. The client merges the SYSTEM tag into the existing XML document. The Editor UI now 
has the complete XML. 



Dispatcher response: 

HTTP/1.1 200 OK 

Content-Type: text/xml; charset="utf -8" 
Content -Length: length 
Sessionld: 175a :dc8e0de306: -8000 



<?xml version^"! . 0 W ?><RESPONSE> 
<PROCESS>new Checkin</PROCESS> 
<STATUS>200</STATUS> 
<ERRORCODE>OK< / ERRORC 0DE> 
<MESSAGE>OK</MESSAGE> 
<SYSTEM> 

<FRAGMENTID>46ba850dc8cflf3cl007f33-Tfrg.xml</FRAGMENTID> 
<CREATOR>Joe Doe</CREATOR> 
<KODIFIER>Joe Doe</MODIFIER> 

<CREATIONTIME>2000-01-07-14 .08.09. 328000</CREATIONTIME> 
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< LAS TMODI FI EDT IKE 2 /LASTMODIFIEDTIME> 

< PAGET* PE> Fragment < / PAGETY PE> 
<CONTENTSIZE>537</CONTENTSIZE> 

</SYSTEM> 
</RESPONSE> 

If the fragment about to be checked in has an accompanying content file, i.e. a multimedia asset 

or an XSL style sheet, the Editor UI encodes the contents using Base64encoding into the 

CONTENT element in the XML. On the server side, the Dispatcher un -encodes it and writes the 

file to the file system, as described in Section XXX. This method avoids sending multiple 

requests to the Dispatcher and having to maintain state between two requests. 

Caveat presently we are unclear on whether there is a size limitation to this method! And it is 

slow! 

Check-In of Modified Fragment 

If the Editor UI checks in a modified fragment or page, it will have received a locktoken from 

the Dispatcher before checking it out. The check-in request in this case must include the 

LockTocken header field T _ ^ - 4 Dieted: 



Client Request 

PUT fragment id HTTP1 . 1 

Host: f ranklinservex/franklinservlet 

Content -Type : text/xml; char3et- H utf-8" 

Sessionld: 175a:dcBe0de306 : -8000 

Content-Length : length 

LockTocken : 

The dispatcher verifies that the correct lock token is supplied with the PUT request before it 
processes the request The dispatcher changes the MODIFIER and the LASTMODJFIEDTIME 
fields in the SYSTEM element. 

After the check-in command, the Editor UI issues an unlock command using the appropriate 

LOCKTOKEN. 

Client request: 

UNLOCK /1234 5678-tfrg.xml HTTP1.1 
Host: franklinserver/franklinservlet 
Sesaionid = 175a : dc8e0de306:-8000 
Locktocken - 12345678 

The Dispatcher verifies the locktoken as described in Section XXX, and returns an OK if the 
token is correct, otherwise it sends one of the two Franklin lock errors: 

# LI 0 1 ■» Lock tokens do not match 

# L102 = Missing lock token 
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Check-out 



To check out a Segment for editing from the Franklin Server, the Editor UI first requests a lock 
for the given fragment, as defined by the WebDAV protocol. 

Client request: 

LOCK /12345678-tfrg.xmi HTTP1 . 1 
Host : f r an kl in server /f ranfclinservlet 
Sessionid - 175a:dc8e0de30 6 :-8000 

If the fragment is already locked by another user, the dispatcher returns a response with 
information on who has locked it when, in case the user wants to contact the person who holds 
the lock. 

Dispatcher response: 

HTTP/1.1 |2$GL0K _ 

Con tent-Type : "text/xnQ ; cna rs et= " ut f - 8 " 

Content-Length: length 
Sessionid: 175a;dc8e0de306: -8000 

<?xmi version« w 1.0*?> ■ 
<RESPONSE> 

<PROCES S>Loc Jc</ PROCES S> 

<STATUS>200</STATUS> 

< ERRORCODE >OK</ERRORCODE> 

<MESSAGE>Loc ked< /MESSAGE> 

<LOCK> 

<LOCKEDBY> Jane Man»** /t ^KEDBY> 

<WCKTIME> 'LOCKTIME> 
</L0CK> 
</RESPONSE> 

If the fragment is not already locked and if the user with the sessionid is allowed to edit 
documents based on the DTD of the requested fragment, the dispatcher creates a unique lock on 
the fragment as described in section Dispatcher: Lock Management. It also sends the lock token 

back in the response. 

Dispatcher response: 

HTTP/1.1 200 OK 

Content-Type: text/xml; coarset-"utf-8 " 
Content-Length: length 
Sessionid: 175a :dc8e0de306 :-8000 

<?xml version^"!. 0"?> 

<RESPONSE> 

< PROCES S>Lock</ PROCES S> 

<STATUS>200</STATUS> 

<ERRORCODE>OK</ERROPJCODE> 

<HESSAGE>OK</MESSAGE> 

<LOCK> 

<LOCKEDBY>Joe Koe</LOCKEDRY> 

<LOCKTIME> * /L0C KTIME> 

<LOCKTOKEN>12345678</LOCKTOCKEN> 
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</LOCK> - 
</RESPQNSE> 

Now the Editor UI can request the fragment for editing using the lock received from the server. 
Client request: 

GET /12345678-tfrg.xml HTTP1.1 

Host: franklinserver/franklinservlet 

Content-Type: text/xml; charset="utf-8" 

Locktocken - 12345678 

Sessionid = 175a :dc8e0de306: -8000 

The Dispatcher compares the lock to the one saved in the Meta Data Store. If they match, 
Dispatcher responds by sending back the complete XML of the fragment. 

Dispatcher response: 

HTTP/1.1 200 OK 

Content -Type: text/xml; charaet= n utf-8 rT 
Content-Length: length 
Sessionid: 175a :dc8e0de306 :-8000 

<?xml version^'l . 0"?> 
<!DOCTYPE PRODUCTPAGE SYSTEM "http : //franklins erver/dtd /productpage . dtd"> 
<PRODUCTPAGE> 
<SYSTEM> 

</SY3TEM> 

</PROD0CTPAGE> 

The Editor UI retrieves the DTD of the checked-out fragment from the server if it has not yet 
toaded h. Using the DTD it auto-generates the UI widgets and then fills in the existing values 
from the checked-out fragment, adding new instances of elements using the +/- mechanism when 
necessary. 

The editor can modify the fields in the same way as when creating new content. Upon check-in 
the Dispatcher updates the lastmodifedtime and modifier fields in the system data of the 
checked- in XML document 

Search 

Clicking on the Search icon in the Editor UI brings up the Search dialogue shown below: 
[insert Search screen shot here] 

When launched, the Search dialogue parses franklinjnit.xml and stores attributes, operators and 
allowed values into hash tables. It dynamically generates the widgets for the query composition. 
When new attributes or values are added to franklin Jnitxml, the Search code does not need to 
be updated. 

The Search UI communicates with the Dispatcher using the Distributed Authoring Search 
Language (DASL) [add refj, an extension to the WebDAV protocol. Franklin Server defines the ' 
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"Franklin" name space which allows the insertion of properties that correspond to the names of 
the indexed elements in Franklin Meta Data Store; 

An example of a DASL exchange between Search UI and Dispatcher is shown below for the 
example Boolean query: 

(AND 

(PAGETYPE "is" "Fragment") 
( LASTMODIFI EDT I ME w gte" " 
{CREATOR "is not" w Jeff Milton^)) 

Search request 

SEARCH / HTTP1.1 

Host: franklinserver/franklinservlet 
Content-Type: text/xml; charaet- n utf-8 " 
Sessionid » 175a:dc8eOde3O6:-8O00 

<?xml .version- w 1.0 w ?> 

<d:searchrequest xmlns: d= "DAV : " xmlns : f -"Franklin : "> 
<d:baaicsearch> 
<d : select> 
<d:prop> 

. <f : FRAGMEMTID/> 
<f:DTD/> 

< f : LASTMODI FIEDT IME / > 
<f:TITI,E/> 
<f:CREATOR/> 
</d:prop> 
</d;select> 
<d: f rom>. 
<d:scope> 
<d:href /> 

<d : depth>inJEinity</d : depth> 
</d: scope> 
</d: frora> 
<d : where> 
<d ; and> 
<d:eq> 

<d:prop> <f :PAGETYPE/> </D:prop> 
<d: lj teral>Fragment</D:literal> 
</d:eq> 
<d:gte> 

. <d:prop> <f :0 J ASTMODIFIEDTIME/> </D:prop> 
<d:literal>1999-10-10</D:literal> 
</d:gte> 
<d:not> 
<d:eq> 

<d:prop> <f:CREATOR/> </D:prop> 
<d : literal>Jef f Milton</D : li teral> 
< /d : eq> 
</d:not> 
< /d : and> 
</d:where> 
<d:limit> 
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<d:nresuits>2</d :nresults> 
</d:limit> 
< /d : ba sic s ea rch> 
</d : searchrequest> 



Hie Dispatcher passes the query to the Meta Data Store where the query is converted to SQL arid 
executed against DB2. The results are converted back to the DASL format 

Currently, we are using the d:nresuJts tag to indicate a range of results to be returned, (e.g. 
<d:nresults>l-50</d:nresults>) This enables the client to request subsequent "pages'! from a 
search with a large number of results. 



Dispatcher response: 

HTTP/1.1 207 Multi-Status 

Content-Type: text/xml; charset= w utf -8" 

Content-Length : length 



<?xml version*- w 1.0 tt ?> 

<d:inulti3tatu3 xmlns :d= n DAV : - xmlns ; f* w Franklin : "> 
<f : responsesuinmary> 




J^^sa 

</f ; responsesumraary> 
<d: response> 

<d:href>http: //f ranJcl in. adtech.ibm. com/4 3 98754 8-tfrg.xmK/d: href > 
<d:propstat> 

<d : prop> 

<f : FRAGMENTID>43987548-tf rg.xraK/f : FRAGMENTID> 
<f ; DTD>Textf ragment</f : DTD> 
<f : PAGET YPE>Fragment< /f : PAGETYPK> 
<f :LASTMODIFIEDTIME>:' 

< / f : LASTMOD I FI E DT I ME> 

<£:TITLE>Lou Geratner's bio</f : TITLE> 
<f :CREATOR/>Joe Moe</f : CREATOR> 
</d:prop> 
</d:propstat> 
</d;response> 
<d:response> 

<d:href >http : //franklin . adtech . ib*a. com/9999999-f rg. xml</d : href > 
<d:propstat> ■ 
<d:prop> 

< f : FRAGMENTI D> 9 9 9 9 9 9 9 - t f r g . xml< /f : FRAGMENT I D> 
<£ : DTD>Listf ragment</f : DTD> 
<f : PAGETYPE> Fragment < tf • P(v£;v.tyt>k> 
<£ : LASTMODI FI EDTIME> 
</f : LASTMODI FI EOT IME> 

<f :TITLE>Highlights for Netfinity 8500R</f :TITLE> 

< f : CREAT0R/> Jane Mane < / f : CREATOR> 
</d:prop> 

</d:propstat> 
</d: £esponse> 
</d:multi3tatua> 
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The Search UI parses the results and displays them in the results table. From the table, the editor 
can select items and merge them into the Active List in the Editor UI. 

Future: If more than the requested number of hits exist in the database, the Search UI uses the 
responsesummary element in the result list to determine how to manage the "Next" and 
"Previous" buttons that allow further results or to go back to a previous set of results. 

Preview 

Before checking in a servable, the editor can preview the final page to be published. The preview 
icon in the Editor UI is active only when editing a servable. Requesting a preview sends a 
request to the Preview Manager servlet with the temporary contents of the servable XML. The 
Preview Manager expands the servable with contents of any subfragments, assembles the page 
with all included style sheets using LotusXSL, and returns the resulting HTML output to the 
client. 

The Editor UI launches the web browser specified in the frankiinproperties file and displays the 
temporary output Once satisfied, the editor can check in the servable. Servables previously 
checked in (e.g., servables returned as search results) can also be previewed. 

(Future: preview of an HTML page does not indicate to the editor which fragment produced any 
given area of the page. Need to devise a way to display the source element.) 

Dispatcher 

Session Management 

When a user logs on using the Editor UI, as described in the Section Editor Interface & 
Dispatcher Communication: Login, the dispatcher checks for a valid user and password by 
consulting the DOM, generated at startup, which contains all user information. If they are valid, 
the dispatcher adds the user to the currentusers hash table and generates a unique session 
identifier, sessionld. Sessionld is created using the java UJDQ call that guarantees to return a 
unique identifier for the machine the process is running on. 

If the same user logs on a second time from another terminal without terminating the earlier 
session, the earlier sessionld in overwritten by a new one, and the old session becomes invalid. 

At logout, the users entry is removed from the currentusers hash table. 

Future: the class that manages the user sessions must be serializable, so that its state can be 
saved and reloaded if the Franklin Server servlet needs to be restarted. 

System Data Creation 

When a dispatcher receives the check in request from the Editor UI, it handles new and modified 
fragments differently. 
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For a new fragment, the Dispatcher fills in the following so-called system elements in the DOM 
built from the incoming fragment: 

<SYSTEM> 

<FRAGMENTID>4 6ba850dc8cflf3cl007f33-tfrg.xml</FRAGMBNTID> 
<CREATOR>Joe Doe</CREATOR> 
CMODIFIER>Joe Doe</MODTFTRR^ 

<CREATIONTIME>: /CREATIONTIME> 
<LASTMODiriEDTXKE> LASTMODI FIEDTTME> 

< PAGET YPE>Fragment</ PAGET YPE> 
<CONTEHTSIZE>537< /CONTENTS! 2E> 
</SYSTEM> 

fragment id is the unique identifier for the fragment This identifier is created using the java 
UIDQ call which returns a guaranteed unique identifier for the machine where the process is 
running. To the UID, the dispatcher appends the suffix -tfrgjcml for simple fragments, -bfrgjanl 
for compound fragments, or -tsrv.xml for servables. To know which suffix to append, the 
dispatcher consults the dtdloType hash table, built at startup to cache the mapping between 
DTDs and their types. 

creator is the name of the user who originally checked in the new fragment. The dispatcher gets 
this name by calling the sessionidToUser method, which retrieves the user name from the 
currentusers hash table based on the sessionld. 

modifier is the name of the user who is currently checking in the fragment, modifier and 
creator are the same when creating the system data for a new fragment. 

CREationtime is the Java generated time stamp of the system data creation time at original 
check-in. 

lastmodifiedtime is the Java generated time stamp of the system data update time at 
subsequent check-ins. creationtime and lastmodifiedtime are the same for a new 
fragment 

pagetype is set to either "fragment- or "servable". The dispatcher sets pagetype by 
consulting the dtdToType hash table, built at startup to cache the mapping between DTDs and 
their types. This field is important because processing of fragments and servables is different in 
the Editor Ul as well as in the content store module. 

contentsize is the size in bytes of the checked-in fragment including any included binary data. 
The dispatcher calculates this after filling in the system data but before extracting any binary 
data. Thus, this is the size of the string being sent over the network between Editor UI and the 
dispatcher. 

Name Space [Management 

The name space manager module of the dispatcher manages all reading and writing of files It 
abstracts away the actual file system from ail other modules, so that they do not have to keep 
track of specialized directories. 
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The name space manager provides the functionality to read and write into the file system DOMs, 
wnrcsponding XML strings that represent fragments or servables. At dispatcher, startup, the 
initialization file is read in, and the variables defining the directories become available to the 
name space manager. 

When writing a compound fragment, the name space manager also extracts any encoded 
multimedia files and style sheets and writes them into the appropriate directories. On the other 
hand, when reading a compound fragment, it encodes any external files into the XML and 
returns the DOM to the module requesting it. 

In addition to the dispatcher, the content store uses the name space manager as well. The content 
store uses it to read fragments from the file system and to write HTMIVHDML/DHTML output 
files from page assembly into the file system. 

The advantage of separating the name space manager from the rest of the Franklin server is to 
isolate the knowledge about dedicated file system directories to one module. For example, if 
xmlDir needed to be split up into a series of second-level directories to limit the size of any one 
directory, only the name space manager would need to know about the change. Under xmlDir 
could reside 10 child directories 0/, 1/, . . .9/ and a fragment would be stored in one of them based 
on a load-balancing algorithm handled by the name space manager. 

Coordination Between Modules at Check-In 

[describe the 3 phase save to file system, meta store and tm, with the fact that tra is 
asynchronous. Maintenance of pending jobs table by dispatcher, and roll-back] 



Lock Management 

As described in the sections Editor Interface & Dispatcher Communication: Check-in and 
Check-out, the Editor UI and dispatcher exchange lock tokens during the LOCK and UNLOCK 
requests from the Editor UI. 

When the dispatcher issues a lock token, it uses the Java U1DQ call to create a unique identifier 
It sends the token along with the user name and the lock time to the Editor UI in the body of the 
response and stores another copy of this information in the meta-data store as described in the 
section Meta Data Store: Lock Management 

When ^ the dispatcher receives an UNLOCK request with a lock token from the Editor UI it needs 
to verify that the token matches the one stored in the meta-data store. If they match, the ' 
dispatcher issues a call to delete the lock in the meta-data store. 

The dispatcher has two other ways to manage locks if problems occur. If the Editor UI requests 
that all locks held by the current user be released, the dispatcher issues the call 
releaseLockByUser to the meta-data store. When the dispatcher is restarted due to a system 
crash, all pending locks in the meta-data store can be released at startup with the call 
releaseLockAU. 



34 



PAGE 35/41 * RCVD AT 4/15/2005 5:50:1 1 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-1» * DN1S: 8729306 * CSID:561 089 OS 12 * DURATION (mm-ss): 14-34 



04/15/2095 17:56 561-989-9812 



FLEIT KAIN ET AL. 



PAGE 36/41 



Error Handling 

All Franklin server side components abide to the same Franklin error handling scheme When 
any of the components called by dispatcher, namely meta-data store, name space manager user 
manager, or content manager, catch or throw a Java exception, they convert it to a Franklin 
exception and fill in all details about the context and the conditions where the error occurred. 

A Franklin exception contains the following attributes: 

myError - the Franklin error code 

myHtipError - the HTTP error code corresponding to the Franklin error code 
myMessage- explanation of error, presented to user of the Client application 
myDestination - one of ERRORJJSER, ERRORLOG, ERROR ADMIN to indicate 
where the error should be directed ~ 
myException - the originally caught exception, if there is one 

The dispatcher module routes the exception based on the attributes. If myDestination is set to 
ERRORUSER, the dispatcher returns the exception to the Editor UI which displays the error to 
the user. If it is set to ERROR_LOG, the error is written to the error log file, and for 
ERROR ADMIN, the process notifies the system administrator. 

Meta Data Store 

The meta-data store allows the indexing and searching of fragments and servables All or a 
subset of the XML elements can be set to be indexed. For a large content site this allows users to 
quickly locate content objects of interest. The meta-data store also manages the lock information 
of content objects. 

DB2 XML Extenders 

Franklin uses XML Extenders for DB2 to index a subset of the XML elements of fragments and 
servables. To accomplish indexing, XML Extenders uses a Document Access Definition CD AD) 
that maps an XML element to a column in a DB2 table. 

DB2 XML Extenders provides two different methods, namely XColumn and XCollection We 
have implemented both methods in Franklin and decribe both in this document. We recommend 
using the XCollection as it is more flexible. 

XCotumn 

The current XColumn implementation of XML Extenders can only map one DTD to one or more 

tabIe f' In order to raa P a" Franklin DTDs to one or more common tables, the dispatcher 
T V ^f™ D J D V° a s °- ca,led ntvrsa! DTD, which contains all elements to be indexed in the 
set of DTDs. For this universal DTD, two DADs are created based on the XML Extenders 
syntax. 

Two DADs are needed, because the current XColumn implementation does not support inserting 
elements that occur only once in the XML and those that occur more than once using a single 
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DAD. Thus, the examples in this section show two DADs that map values from the universal 
DTD. . . 

When designing the DADs, ail elements that appear only once, or single-occurrence elements, 
can be mapped to one table. Any elements that can appear more than once, or multi-occurrence 
elements, need to be mapped each into separate dedicated tables. The administrator creates a 
view between the single-occurrence table and the multi-occurrence tables to perform searches 
across all tables with one command. 

A DAD specifies the following items: 

table name ~ name of the DB2 table 

column name = name of the column in the encapsulating table 
column type « data type of the column 

column path = XPath expression from the root to the element to be indexed 
in the column 

column multi -occurrence — flag to indicate whether the element at the path 
can occur more than once 

Example of a DAD mapping single-occurrence elements: 

<?xml vers ion-" 1 . 0"?> 

<!DOCTYPE DAD SYSTEM "c: \dxx\f ranJclin\dtd\universal . dtd"> 
<DAD> 

<dtdid>UNIVERSALDTD</dtdid> 
<validation>NO</validation> 
<Xcolumn> 

<table name ="META .MAIN" > 
<column name= "CREATOR" 
type="varchar (50) *' 

path= " /ONI VERSAL /SYSTEM /GREAT OR" 
raulti_occurrence«"NO"> 
</column> 

<column name=*"CREATIONTIME n 
type="TIMESTAMP" 

path= M /UWIVERSAL/SYSTEM/CREATIONTIME" 
mul t i_occurrence= "NO " > 
</column> 

< column name— "LASTMODIFXEDTIME" 
t ype«= "TIMESTAMP " 

path-VONIVERSAL/SYSTEM/LASTMODIFIEDTIME" 
multi_occurrence= ; ' , NO ,T > 
</column> 

<column name="PAGETYPE n 
type«"char {10} n 

pa th=" /UNIVERSAL /SYSTEM/PAGETYPE" 
raulti_occurrence="NO*> 
</column> 

< column name- "CONTENTS I ZE" 
type="integer" 

path= w /OKFIVERSAL/SYSTEM/CONTENTSI2E ,f 
multi_occurrence= n NO rt > 
</column> 

<column name= "TITLE" 
type="varchar C250) " 
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pat h= "/UNIVERSAL /TITLE" 

multi_occurrence«"NO n > 
</column> ' . 

<Column name="DOCTYPB° 

type- w var char ( 32 > " 

path= " /UNIVERSAL /DOC TYPE " 

multi_occurrence=**NO n > 
</column> 

<column name- "DTDURL" 
type- " varciiar (512)" 
path*- » /UNIVERSAL /DTDURL" 
raul t i_occur r ence=» n N0" > 
</column> 
</table> 
</Xcolumn> 

Example of a DAD mapping multi-occurrence elements: 
<?xml version^"l .0"?> 

<1DOCTYFE DAD SYSTEM "c : \dxx\f ranlclin\dtd\uriiversal . dtd"> 
<DAD> 

<dtdid>DKIVERSALDTD</dtdid> 
<validation>NO</ validations 
<Xcolumn> 

< table name™ "MET A. CATEGORY "> 
<colunm name- "CATEGORY" 
type-" varchar ( 12 8 ) TO 
patb=V UN I VERSAL /CATEGORY " 
multi_occurzence- w YES H > 
</column> 
</table> 

<table name ^"META. KEYWORD "> 
<column name- "KEYWORD" 
type="varchar (64) " 
path=" /UNIVERSAL /KEYWORD" 
multi_occurrence— "YES"> 
</column> 
</table> 
</Xcolumn> 
</DAD> 

The tables created by these DADs are shown in the Section Table Design. 
/Collection 

The XCoUection implementation of XML Extenders requires one DAD for each DTD to be 
mapped into DB2. Unlike XCoIumn, different DTDs can be mapped to the same DB2 tables. 
Thus, the XCoUection implementation does not required documents to be converted to abide to 
one universal DTD. 



[However, the current XCoUection also has a few problem. We have implemented a temporary 
fix into the meta data store until the problems are addressed] 

The DAD corresponding to textfragrnent.dtd is shown below: 
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[add DAD here] 



Table Design 

When a DAD is loaded into DB2, the tables and columns specified in it are automatically 
created. After the tables are created, the administrator needs to add the following items to the 
database: 

- a column named ISCOMMIT in the table storing the single-occurrence elements. This 
column indicates if the fragment has successfully been committed to the content store 
and file system 

- indexing on any columns that will be searched 

- a view which combines data from all tables for searching 

The database tables created by the previous DAD examples are shown below, along with keys 
indexes, and the ISCOMMIT column created by the administrator. 

Schema : 

META: Used for all the tables used by Franklin 
INDEX: Used for all the indexes used by Franklin 

Tables Generated by DAD: 

META. MAIN: This table contains all the elements that occur at most once in 
the input XML document 



Column Name 

FRAMENTID 

CREATOR 
CREATION TIME 

LASTMODIFIEDTIME 

CONTENTS IZE 
TITLE 
PAGET YPE 
DO.CTYPfc 
DTDURL 

ISCOMMIT 



Data Type 

CHAR<56) 

VARCHAR (50) 
TIMES TAMP 

TIMESTAMP 

INTEGER 
VARCHAR 
CHAR (10) 
VARCHAR (32) 

VARCHAR (512) 
INTEGER 



Default 



Key 

Fk -> 
unifragl 



Index 

index. fragment 
id 

index. creator 
index . creation 
time 

index . lastmodi 
fiedtime 

index. title 
index -pagesize 
index. doctype 
index . dtdurl 



gi"„™H T x£ 3 table COntai " 3 the KEYW0RD ele — associ - ed - 



Column Name 
FRAMENTID 



Data Type 
CHAR (56) 



Default 



Key 

Fk -> 
unifrag2 



Index 

index- fragment 
ed 
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KEYWORD • VARCHAR(64) index. keyword 

MET A. CATEGORY: This table contains the CATEGORY elements associated with a 
given FRAGMENT ID . 



Column Name Data Type Default key index 

FRAMENTID CHAR(56) * fk 

CATEGORY 



index . fragment 
id 



VARCHAR < 1 2fl > index _ category 

UNI FRAG 1 : This table contains two fields. 

Fragmented . - the f ragiaentid for a given XML file 
Fragmentxml - the XHL file stored in the file system 

The function of this. table is to trigger filling MET A . MAIN when a record is 

inserted 



Column Name Data Type Default key index 

FRAMENTID CHAR (5 6) PK 

FRAGMENTXML 

DB2XML . XMLFILE 

DNIFRAG2: This table has the same structure as ONIFRAG1. The function is to 
trigger filling MET A . KEYWORD and MET A . CATEGORY when a record is inserted 

Column Name Data Type Default key index 

FRAMENTID " CHAR {56) p K 

FRAGMENTXML 

DB2 XML. XML FILE 

Index 

When a fragment or servable is checked in, the dispatcher converts the XML file to abide to the 
umversa DTD for indexing in the XColumn implementation. After the conversion, it sends the 
umversai XivlL to the meta-data store. In the XCoHection implementation, the fragment or 
servable is sent as is to the meta-data store. 

For XCoHection, the meta-data store enters a pointer to the file into the two tables named 
DNiTFRAGi and cnifrag2 in the previous example. When the record is entered, a trigger copies 
the elements specified in the DAD to the appropriate tables. The elements are now ready for 
searching. 

For XColumn ... 
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Search 

When the Search UI sends a DASL search expression, described in the section Editor Interface & 
Dispatcher Communication; Search, to the dispatcher it passes it directly to the meta-data store. 
The meta-data store converts it to an SQL expression, executes the SQL query and converts the 
results to the DASL output formal 

An example DASL query: 
<?xml version= w l .0"?> 

<d:searcnreguest xmlns:d-"DAV: " xmlns : f= w Franklin: "> 
<d: basics earch> 
<d:select> 
<f :prop> 

<f :FRAGMENTID/> 
<f :DOCTYPE/> 
<f : LASTMODIFIEDTIME/> 
<£:TITLE/> 
<f: CREATOR /> 
<f :PAGETYPE/> 
</f :prop> 
</<X : 3elect> 
<d:from> 
<d: scope> 
<d:href/> 

<d:depth>infinity</d:depth> 
</d: scope> 
</d:from> 
<d:where> 
<d : and> 
<d:like> 
<d:prop> 

<f:KEYWORD/> 
</d:prop> 

<d : literal>SERVER</d : literal> 
</d:like> 
<d:Iike> 

<d:prop> 

<f :PAGETYPE/> 

</d:prop> 

<d:litexal>FRAGMENT</d:literal> 

</d:like> 

</d:and> * ' 

</d:where> 
<d:limit> 

<d;nresults>l-50</d:riresu2ts> 
</d;limit> 
< /d : basics ear ch> 
</d : searchrequest> 

The above DASL query converted to SQL: 
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